The Standard Model

Work in progress

The Standard Model introduces a large number of new features, functionality and, especially, data sources, many of which warrant extensive documentation. This section (and other affected sections of this Help) will be updated as each of these new features is documented; as a feature is documented, it will be announced on the Home page and in What's new in the Help.

Our most comprehensive data management environment to date

With the Standard Model the number of fields available out-of-the-box has increased significantly so that there is almost certainly a suitable field to hold your data without the need for customization. This, in turn, has allowed for a repurposing of free fields (described below). Previously, free fields were used sparingly in Axiell Collections, typically only used to hold data migrated from fields in legacy systems that had no obvious equivalent in Collections. By expanding their availability across more data sources, and providing more types of free field (to hold not only text, but dates and numbers, etc.), free fields are now available as an alternative, where appropriate, to customization of the application: if there is no native field for a piece of data, consider whether free fields can be used, rather than customizing the application by adding a new field.

Many new data sources have been introduced and some existing data sources have been expanded to enhance their usefulness; and last, but not least, 100 ADAPLs Both a general-purpose programming language and a program built in the ADAPL language. An ADAPL program can be executed as a standalone program or used during various database functions, e.g. to validate data input, or to carry out an additional check during record deletion. have been added. Together these enhancements and expansion of the data management heart of Collections reduce the need to use Axiell Designer to create fields, data sources, validation logic and other customizations as they are already available.

Reduced reliance on Axiell Designer for administration and configuration

Several new data sources enable Application Administrators to manage some system configurations and customizations in Axiell Collections itself, including the specification of default values and the management of system lists (lists of controlled values such as condition terms, method types, action types, fee activities, acquisition reasons, units, etc.).

While assignment of users to groups is still managed with Axiell Designer (by your Application Administrator or Axiell Support), the standardization of the permissions model and the availability of user groups out-of-the-box with the Standard Model eliminate the need to build a permissions model from scratch for each new implementation of Axiell Collections (details below).

Details

The Standard Model introduces a new record summary field available in every data source The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on., and, in Record details View, two panels in most data sources that improve support for procedural, administrative and financial data:

the Actions panel is used to plan or register a range of actions such as meetings, reviews, photography sessions, etc.
the Expenses and income panel is used to register costs of activities such as cleaning, insurance, crate construction, painting, shipping, etc.

Tip: Application Administrators can extend the lists of actions or expenses in these panels by adding new action types or fee activities in the System lists data source.

While not new to Axiell Collections, free fields and the Free fields panel have been improved and made available across more data sources. The Free fields panel provides a location for any data that does not have a native field in Collections, and it is intended as an alternative, where appropriate, to customization of the application.

Tip: The Common panels topic assembles the following descriptions of panels and descriptions of several others that are widely available.

Also introduced with the Standard Model and available in every data source is the Record summary (record_summary (Z0)) field, a field that provides an auto-generated summary of a record's key data taken from one or more key fields in a record.

And finally, it is now possible to mark a record as read-only when there is no longer a reason to alter it.

Actions panel

The Actions panel is a basic workflow tool designed for managing tasks (actions) relating to the current record. The type of action tracked depends on the data source you are working in (actions in the Catalogue will not necessarily be the same as actions in Loans for instance); actions might include anything from scheduling meetings, reviews, to photography sessions, etc. Managing tasks might entail scheduling an action (a meeting for instance), tracking an action's progress (the crate has been ordered) or documenting that an action has been performed (the object was moved). This functionality is not meant to replace dedicated project management software, but it can be used to prescribe standard procedural tasks (setting default actions) and to track and log tasks relating to the current record.

Default and conditional actions

Application Administrators can define default actions for any new record in the System admin – occurrence defaults data source.

If an action is required when certain conditions are met, occurrence defaults can be set up to facilitate this; for example, in Acquisitions and acquisition proposals a Send Deed of Gift action can be added when a record has an Acquisition method (method (sm)) of gift and a Status (current_status (sS)) of approved.

An example Actions panel

Although the actions we document and track may differ from one data source to another the method for using the panel is the same. Here we see the Actions panel in the Acquisition items data source, where we select actions from the Type drop list that affect an item during its acquisition:

The purpose and use of many fields are clear and straightforward, and we only highlight those of particular importance below:

Field / System name	Details
Type / action.type (U0)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to the Thesaurus. Start typing the term for an action and select it from the drop list, or click the Link icon to display the Find data for the field box; search for the relevant term or create a record in the Thesaurus and link to it (if authorized to do so). Actions might include: acquisitions meeting, conservation review, meet with donor, etc. Tip: Application Administrators can add additional action types in the System lists data source. Details about working with the Find data for the field box can be found here.
Responsible / action.person_responsible (UA)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to Persons and institutions. Start typing the name of the person responsible for the action and select it from the drop list, or click the Link icon to display the Find data for the field box; search for the relevant person or create a record in Persons and institutions and link to it (if authorized to do so). Details about working with the Find data for the field box can be found here.
Requested by / action.requested_by (U6)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to Persons and institutions. Specify the person who requested the action.
Request date / action.request_date (uA)	The date on which the request was made. Type a date or click the Calendar icon to select a date (details about date fields and how to use the Calendar can be found here).
Priority / action.priority_level (Uc)	Drop list of values. Indicate the priority of the action: non-priority low medium high
Date due / action.date_due (u2)	The date the action should be completed.
Start date / action.date_start (U1)	The date the action commenced.
Date completed / action.date_complete (U4)	The date the action completed.
Confidential? / action.confidential (U9)	Checkbox indicating the sensitivity of the action. Tip: Although selecting the checkbox does not trigger any action in the software, it could be used by a script to exclude confidential actions when running a report, for instance.
Status / action.status (U8)	Drop list of values. Select the current status of the action: pending pending approval approved open suspended completed rejected cancelled
Status date / action.status_date (u8)	The date the status was set.
Rec. Ref. / action.record_reference (u9)	Short for Record reference: if an action is part of a larger project, enter the reference number for that project. Although there is currently no functionality built around this or the following field, Job no., it is anticipated that an Action Request tool will become available in a future release that will connect individual actions back to an original request or project.
Job no. / action.job_number (uB)	Used for internal numbering of individual actions. This is useful if actions are generated (or referenced) by an originating Action Request.
Description / action.action_text (u1)	Provide detail about the action. As Type is a Linked field, Description can be useful for providing nuance for what is expected from an action.
Notes / action.notes (u7)	Document any outcomes, problems, or information that might be helpful for completing the action.

Expenses and income panel

The Expenses and income panel is available in data sources where costs and / or income are incurred for activities relating to the current record, such as cleaning, insurance, crate construction, painting, shipping etc.

Note: In data sources where income is not generated but expenses are incurred, the panel is called Expenses and it does not include the Direction column.

For each activity, the cost can be registered, and totals calculated.

A line item can be for a specific item in your collection, in which case you would select an object number from the Item drop list, or it can be a general cost unrelated to a specific item, in which case you can ignore the Item drop list.

The purpose and use of many fields are clear and straightforward, and we only highlight those of particular importance below:

Field / System name	Details
Activity / cost.activity (Pa)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to the Thesaurus. Start typing the term for an action and select it from the drop list, or click the Link icon to display the Find data for the field box; search for the relevant term or create a record in the Thesaurus and link to it (if authorized to do so). Expense activities might include: cleaning, crate construction, shipping, etc. Income activities might include conservation (performed for external clients), licencing (fees for use of collection items by third parties), ticket revenue, etc. Tip: Application Administrators can add additional activity types in the System lists data source. Details about working with the Find data for the field box can be found here.
Name / cost.name (Pb)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to Persons and institutions. Start typing the name of the person responsible for the activity incurring the cost / generating income, or click the Link icon to display the Find data for the field box; search for the relevant person or create a record in Persons and institutions and link to it (if authorized to do so). Details about working with the Find data for the field box can be found here.
Direction / cost.direction (Pe)	Indicate whether the activity generates income or is an expense. Drop list of values: income expense
Item / cost.item.link (PI)	A drop list of object numbers for items in your Catalogue. If the line item relates to a specific item in your collection, select its object number from the drop list; otherwise ignore this drop list.

Free fields panel

When we talk of types of field we typically refer to the field's data type (date and geolocation fields) or a particular quality (inherited fields). In the case of free fields, it is their purpose that characterizes them.

Most fields in Collections are intended to hold a specific piece of information (an object number, a title, a birth date, and so on) often defined by an industry standard (SPECTRUM or ISAD(G), for instance). Free fields, which are found on a Free fields panel typically near the bottom of the list of tabs in Record details View, provide more flexibility; while not new to Collections, their use in the past was mostly limited to holding data migrated from fields in legacy systems that had no obvious equivalent in Collections.

Note: In systems running Model Applications prior to the Standard Model, there is a single text type of free field.

The release of the Standard Model saw a significant increase in the number of fields and data sources available in Collections so that there is almost certainly a suitable field to hold your data without the need for customization. This has allowed for a new approach to the use of free fields in systems running the Standard Model, and Free fields panels are now intended as an alternative, where appropriate, to customization of the application. To that end, Free fields panels are now available across more data sources; and it is no longer necessary to store all types of data in a generic text field as there are now free fields to hold text, dates and numbers, and there is also a checkbox variant:

Their use is straightforward. You specify the purpose of the field in Type (name the field) and enter the value in the Content field:

Note: As values in the Type field are managed in the System lists data source1, Application Administrators ($ADMIN users) are free to add new values as required.

As each group of fields on the Free fields panel (Texts, Dates, Checkboxes, Numbers) is a repeatable group of fields, you can use the Occurrences drop list in the Record details View toolbar to add / remove / move a group of fields.

If there is no native field for a piece of data, consider whether a free field can be used to hold it, avoiding the need to customize the application.

Read-only records

It is possible to make a record read-only by checking the Read only (record.read_only (zz)) checkbox, allowing the record to be read but no longer edited3.

In most data sources The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on., the Read only checkbox is found on the Management details panel (typically under a Record access heading):

In some data sources (Archives catalogue and Accessions for instance) it is found on a Notes and description control panel:

You would mark a record as read-only when there is no longer a reason to alter it: records for a past exhibition, deaccessioned objects, cancelled acquisitions, and the like.

Once a record that has been marked as read-only it can only be edited by Application Administrators (anyone with $ADMIN access); for everyone else a message will pop-up indicating that the record cannot be edited. For Application Administrators a pop-up will give them the option to re-enable editing of the record:

Tip: A response must be provided within 10 seconds (a count down is shown in the No button); if a response is not provided, the pop-up disappears and the record remains un-editable.

Data sources for (users) managing collections data

With the Standard Model a number of data sources have been expanded and improved (including Persons and institutions, Locations and containers, Exhibitions and venues; and new data sources have been introduced, in some cases by taking fields that were available in a limited form in the Catalogue or another data source and moving them to a dedicated data source, greatly expanding the scope of information that can be documented (including Deaccessions and Disposals, Rights and Licensing, References and citations, Movement history, Movement and shipping logistics, Incidents, Events, Entry, Deliverables, Collections audit). By far the most significant enhancement to collections management has been the introduction of a new category of data source, Items. There are four Items data sources, Acquisition items, Exhibition items, Loan items and Collections audit items; these sit between data sources like the Catalogue and Loans, and they hold extensive granular detail about collection items involved in a particular activity, such as a loan or exhibition.

Here you will find an overview of data sources that are new to Axiell Collections and those that have been expanded and improved with the Standard Model, and a link to more comprehensive information in the Data sources sections of this Help where required.

Data source

New or changed

Details

Assessments and treatments

Changed

Used to manage and track conservation, restoration, and condition checks / assessments performed on items in your collection.

Changes introduced with the Standard Model

In Model Applications up to version 5.2 condition information can be documented in either (or more often both):

an object's Catalogue record: by completing the repeatable A field that is repeatable can have multiple occurrences. A book, for instance, can have more than one author, therefore the Author field can be repeated multiple times to accommodate the need for additional instances of a field (use the Occurrences options in the Record details View toolbar to add occurrences of a field. Condition group of fields on the Condition | Conservation panel;
an Assessments and treatments record, documenting the assessment / treatment work, linked to the Catalogue record for each affected object (read on for details about how to link to objects).

To avoid any ambiguity about where details are recorded, condition information is only documented in an Assessments and treatments record in the Standard Model.

An Assessments and treatments record lists the Catalogue record of all affected objects on the Linked objects panel; condition details about each linked object are then documented on the Condition description panel. Details about the Assessments and treatments record automatically display in the Assessment / Treatment log table on the Condition | Conservation panel in the object's Catalogue record.

The recommended way to add one or more objects to an Assessments and treatments record is to use the Add to objects Links option in the Result set View toolbar (the same method applies for all Model Applications):

Creating an Assessments and treatments record in the Standard Model

When creating a record there is the choice of two record types:

Type

Details

treatment

A treatment record can be used to plan treatments, track and manage the status, requests and authorizations of the treatment (on the Treatment details panel):

And to document the full process from pre to post treatment (Treatment process panel):

All available panels:

check/assessment

A check/assessment record can be used to track and manage the status, authorizations and follow-up activities of an assessment (on the Assessment details panel). Note that assessments can have successive follow-up treatment and assessment activities as often as required, each in their own record, via the repeated Requested activity fields:

The Condition descriptors field group on the Condition description panel can be used to link controlled condition terminology to items on the record:

All available panels:

It is possible to create Assessments and treatments records directly in a number of data sources, including:

Loan items - in the Reference number field on the Condition assessments panel;
Incidents - in the Post-incident assessment field on the Objects and containers panel.

As can be seen above, Assessments and treatments records include the Actions, Expenses and income and Free fields panels.

Collections audit and Collections audit items

New

In Model Applications prior to the Standard Model, undertaking a locations check of multiple objects is handled with the Collections review data source; and a more ad-hoc locations check of individual items is managed with the Location checks group of fields on the Location | Future movements panel:

The Standard Model improves locations checking with the introduction of two data sources designed exclusively for this purpose, Collections audit, in which we document and manage the overall status and details of a locations audit, and Collections audit items, in which we document and manage the details of an individual item involved in a locations audit. Task-driven workflows are provided for large scale audits and for more ad-hoc locations checks.

Details about performing a locations check with the Collections audit and Collections audit items data sources can be found here.

Collections review

Changed

The Collections review data source, which was introduced with Model Application 5.0, is used to document and manage formal assessments of collection items, the scope of which might be a few items to the entire collection. A collections review is undertaken to acquire a deeper understanding of the collection, including the condition, provenance, and significance of items.

Collections review has been improved with the Standard Model with the addition of several useful panels, including Digital references, Free fields and Status history, and an improved PIDs and other identifiers panel; however the most significant change is that locations checking, which is a function of Collections review, is now managed far better with the new Collections audit and Collections audit items data sources, described below.

Deaccessions and Disposals

New

Deaccession and disposal are related but distinct processes, typically involving a formal and documented review that takes into account your institution's collections policy, as well as legal and ethical considerations. In Model Applications prior to the Standard Model, deaccession and disposal data is registered in a limited set of fields in Object Catalogue records on a Disposal panel, with a focus on documenting the disposal of an object. The Standard Model moves these fields to a dedicated Deaccessions and disposals data source, greatly expanding the scope of information that can be documented.

Details about how to record deaccessions and disposals can be found here.

Exhibitions and venues

Changed

Previously called Exhibitions. Now used to document and manage the status and details of exhibitions and the venues at which they take place; used in conjunction with Exhibition items (see Items data sources below). Venue records can be used independently of an exhibition, to document the display of items in collection galleries for instance.

Details about how to document exhibitions, venues and exhibition items can be found here.

Insurance and indemnity and Valuation

New

In Model Application 5.2 and earlier, valuation, insurance and indemnity information about objects is managed on the Value | Insurance panel in Object catalogue records. The fields on this panel are adequate for recording key financial and risk management details, but comprehensive valuations, insurance and indemnity documentation of collection items can involve more information and activities (actions) than these fields can accommodate. This is addressed with the Standard Model and the introduction of two data sources dedicated to managing valuations and insurance and indemnity matters: Insurance and indemnity and Valuation.

As well as recording information about the provider, policy, and coverage amount, an Insurance and Indemnity record lists all covered objects, with a link to a Valuation record that assesses an object's value, and it identifies locations and shipments that are covered by the policy. On the Actions panel, a basic workflow tool for managing tasks related to the current record, it is possible to document and manage any related activities (actions), such as scheduling meetings. Digital copies of documentation can be made available on the Digital References panel.

Details about how to document an institution’s insurance and indemnity policies can be found here.

A Valuation record holds valuation details for a specific Catalogue item, including amounts, currency, exchange rate, who conducted the valuation, why it was undertaken and when. On the Actions panel, a basic workflow tool for managing tasks related to the current record, it is possible to document and manage any related activities (actions), such as scheduling meetings. Digital copies of documentation can be made available on the Digital References panel.

Details about how to document object valuation details can be found here.

Items data sources

New

Introduced with the Standard Model, Items data sources are used to document and track collection items involved in day to day activities like loans and exhibitions. In prior Model Applications, when a collection item is on loan its Catalogue record (with details about the item) links directly to a Loans record (with details about the loan); what is lacking is somewhere to record details about the item in the loan, to track the status of each item as it navigates the loan workflow, or to plan actions that impact an item's involvement in the loan. The same is true of items involved in acquisitions, exhibitions and collections audits. Items data sources fill this gap by providing a place to manage and document each item individually as it participates in activities like loans and exhibitions. They include Acquisition items, Exhibition items, Loan items and Collections audit items.

An overview of Items data sources can be found here.

Guidance is provided for working with each of the Items data sources:

Persons and institutions

Changed

New fields, field groups and panels have been added to Persons and institutions, expanding and enhancing data management of individuals and organizations interacting with your collection.

Details

Notable new and changed panels and fields:

Identification panel

Field group

Field

Details

Authorised form of name

Record type / record_type (oG)

Chief amongst the new fields is the Record type (record_type (oG)) drop list on the Identification panel:

While Record type is not mandatory, it is a useful conditional field: selecting a value in the drop list will tailor which fields are available, and potentially auto-populate fields. Enter a name in the mandatory Name field, and select an option from the Record type drop list.

Here we enter a name in the Name field (Surname, Forename or Forename Surname) and select Individual from the Record type drop list:

Tip: In earlier Model Applications it is generally best practice to enter names as Surname, Forename, but that is no longer required with the Standard Model as a name entered as Forename Surname will be parsed and sorted by surname automatically.

A number of things happen:

Name sort is auto-filled with the contents of Name, capitalized; if Record type = Individual, the name is formatted as <surname>, <forename>.
A Person’s name elements group of fields is added below the Authorised form of name group of fields, with Surname and Forename(s) auto-filled.
Note: If, for some reason, the value in Name is not automatically split into its Surname and Forename elements, click the Generate name checkbox.

Name role / name.type (do)

Many more roles have been added to the Name role (name.type (do)) drop list. Name role is an enumerative Read-only drop lists; their values are added and translated by Application Administrators in the Collections administration tool, Axiell Designer: users can select a value in an enumerative field, but cannot add or translate a value. list of domains A subset of records in an Authority data source, grouping similar sorts of records. When a search or Linked field is associated with a domain, only records in that domain are available to that field. For example, records for authors can be assigned to the AUTHOR domain (using the Name Type / name.type (do) field). When linking a record for a book to a record for its author, the Author Linked field will point to the AUTHOR domain, a subset of records in Persons and institutions exclusively for authors. In the Thseaurus, a record is assigned to a domain using the Term Type / term.type (do) field..

A person or institution can have one or more roles in their interaction or involvement with your collection (which is why the field is repeatable A field that is repeatable can have multiple occurrences. A book, for instance, can have more than one author, therefore the Author field can be repeated multiple times to accommodate the need for additional instances of a field (use the Occurrences options in the Record details View toolbar to add occurrences of a field.); a person can be a creator, publisher, borrower, etc. or might only be identified as having a role of person. Roles are important in Catalogue fields that link to the Persons and institutionsAuthority data source; many Linked fields A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). are configured to link to a specific domain so that only appropriate records can be linked to (the Creator field in a Object catalogue is configured to link to people with the creator role, for example).

Name variations

Managing variations in names has been improved. Previously, the Use (use (us)) and Used for (used_for (uf)) fields under Other forms of name on the Identification panel were used to record non-preferred / alternative versions of a name:

Each Use or Used for value is a Persons and institutions record in its own right, which can lead to a proliferation of records.

Now, a more intuitive and efficient Name variations group of fields is provided:

As before, Name (name (BA)) is the authorized form of the name, but now any variations are registered in the repeatable A field that is repeatable can have multiple occurrences. A book, for instance, can have more than one author, therefore the Author field can be repeated multiple times to accommodate the need for additional instances of a field (use the Occurrences options in the Record details View toolbar to add occurrences of a field.Name variations field group, notably Name variation (name_variation.name (vn); unlike before, these name variations are not recorded in separate records.

How does this affect searching and linking?

The Name variation (name_variation.name (vn)) field is indexed alongside Name (name (BA)) so that a search for a name variation will always locate the authorized name: if you enter a name variation in a search field in Persons and institutions itself or a field linked to Persons and institutions, the record with the authorized name will be located. For example, this Standard search in Persons and institutions will return the record for British Broadcasting Corporation:

When linking to a record, a name variation entered into a Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). will pull back the authorized name. Here we see the Persons and institutions for Jan Vermeer, with multiple name variations:

When linking to this record in the Catalogue and entering one of the name variations, the record for the authorized name is located:

and when selected, automatically replaces the name variation:

Contacts panel

Contacts is a new panel used for linking to other records in Persons and institutions where Name role (name.type (do)) = contact. It contains two groups of repeatable A field that is repeatable can have multiple occurrences. A book, for instance, can have more than one author, therefore the Author field can be repeated multiple times to accommodate the need for additional instances of a field (use the Occurrences options in the Record details View toolbar to add occurrences of a field. fields, Contacts and Contact for:

We use this panel to identify one or more contacts for an institution, or perhaps for another person.

Obviously, a person can be a contact for an institution, and a person can be a contact for another person, but an institution could also be a contact for a person, or another institution for that matter. To simplify the following description, we assume that a person is the point of contact for an institution.

In the Persons and institutions record for an institution, we link to the record for someone who is a point of contact using the Name (contact (Cn)) field in the Contacts table; this will copy over details from that person's record (name, address, phone number, email address, etc.). Here we see the Persons and institutions record for Axiell with a contact added to the Contacts panel:

Field	Details
Name / contact (Cn)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to Persons and institutions. Start typing the name of the person and select it from the drop list, or click the Link icon to display the Find data for the field box; search for the relevant person or create a record in Persons and institutions and link to it (if authorized to do so). Details about working with the Find data for the field box can be found here. In Display mode A record is either in Display mode (we view its details) or Edit mode (we add or edit its details). A record enters Edit mode as soon as we create a new record, copy a record in Record details View or edit an existing record., click the link to display the contact's Persons and institutions record.
Contact Type / contact.type (ct)	A Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). to the Thesaurus. Identify what type of contact the party is (e.g. staff member, family member, volunteer, etc.). Start typing a contact type and select it from the drop list, or click the Link icon to display the Find data for the field box; search for the relevant term or create a record in the Thesaurus and link to it (if authorized to do so).
Surname, Forename(s), Prefix(es) to surname, Title and Salutation	Values in these fields are retrieved from the target record A link is made from one record (the primary) to another (the target). dynamically each time the current record is opened.
All other details	Other details, including telephone numbers and email address, are retrieved from the target record A link is made from one record (the primary) to another (the target). when it is added to the Name (contact (Cn)) field; but subsequently these details are NOT updated dynamically if they change in the target record. These fields are editable; if they change in the target record, be sure to update them here.

In the target (linked) record, the Contact for group of fields is automatically updated with details of the party they represent:

Additional panels

Amongst other panels added to a Persons and institutions record in Record details View, you will find Actions, Digital references, and Free fields.

Personally Identifiable Information (PII)

Persons and institutions records may contain Personally Identifiable Information (PII), including birth and death details, ethnicity, gender, nationality, occupation, address details, email addresses, contacts, etc. Under the European Union General Data Protection Regulation (GDPR) guidelines for information privacy in the EU, this data can be regarded as sensitive information; accordingly, access to fields that may contain such data is now protected by access rights by default.

The Standard Model introduces a user management model out-of-the-box with a base set of predefined roles and permissions governing access to advanced and administrator functionality, as well as access to fields containing sensitive data and Personally Identifiable Information (PII), such as personal address fields and email fields.

Full details about the permissions model introduced with the Standard Model can be found here. In brief, two roles have been introduced to control read and read-write fields identified as PII:

PII writer / pii_writer
PII writer / pii_writer

When the Standard Model is installed, staff are assigned a role that matches their access level, ensuring that only people with clearance are able to view and / or edit sensitive personal information.

Details coming soon

Information below is extracted, unpolished, from preliminary release notes:

Data source	New or changed	Details
Deliverables and Access request items	New	These two new data sources are associated with the pre-existing Use of collections data source. The latter data source describes the overarching request, while the Access request items and Deliverables records act as Item records for each individual object either being accessed or reproduced in support of this request.
Entry	New	Movement and Shipping Logistics is used to document planned object movement, but items received unexpectedly can be registered using the Entry data source. A lot more details can now be registered, including information about the depositor, return instructions, and the temporary object number(s) assigned. If more detailed cataloguing is required, Catalogue records can be created via a zoom screen from within the Entry record.
Events	New	The Model Application 5.2 Events data source was specific to film life cycle events (when was the film produced, when published, any award ceremonies): this data source has been renamed to Film lifecycle events. The new Events data source is intended to document historic events (e.g. “D-Day”, “1994 Winter Olympics”) and internal institutional events (e.g. “Donor tour of conservation lab”, “Fall 2024 Collections Committee Meeting”, “School visit”).
Film lifecycle events	Repurposed	The Model Application 5.2 Events data source was specific to film life cycle events (when was the film produced, when published, any award ceremonies): this data source has been renamed to Film lifecycle events. The new Events data source is intended to document historic events (e.g. “D-Day”, “1994 Winter Olympics”) and internal institutional events (e.g. “Donor tour of conservation lab”, “Fall 2024 Collections Committee Meeting”, “School visit”). Beyond general harmonisation with other Standard Model features, such as the introduction of a Record summary field, the Film lifecycle events data source is essentially unchanged from earlier application versions.
Incidents	New	The incidents data source is used to describe damage and loss incidents associated with one or more objects, containers, and/or locations. Because it is not object-specific or object-dependent, it can be used to more effectively document large scale incidents (like floods) which can impact multiple objects / containers. It can also be used to document problems in collections spaces (like pest sightings) even when no harm has been found to objects (yet), so that users can identify and address any patterns of incidents in certain locations. For each included object, users can directly link a condition assessment as part of their incident response. Additionally, the reporter(s), incident type(s), associated people, actions, and other details can be registered. Multiple photos and other media or documents of the incident can be linked as well.
Locations and containers	Changed	Locations and containers are still registered in a single data source. In this application version, the Current location of packed objects is still the container and it will remain the container even if the container is moved. The container itself should of course have a Current location and Normal location. Locations can be part of a location hierarchy which can be registered in the Is part of and Contains sections on the Location details tab. On the Movement history screen tab in container records, you’ll notice a repeatable and clickable Reference number field which links to separate movement history records because the details of a movement history are no longer registered here. The Locations and containers data source offers a lot more fields than before. A couple of fields of interest are the Status drop-down list and the Unavailable, On view and Publish? checkboxes underneath it. The Status drop-down offers the choice between: active, meaning that the user is free to use this location or container. candidate, meaning that the location or container hasn’t been approved yet. Obsolete, meaning that this location or container can’t be used any more. Users will be warned when they still try to use a location or container with this status. The Unavailable, On view and Publish? checkboxes are independent of the Status. Unavailable means that the location is only temporarily unavailable, maybe because it’s being cleaned: there’s no action attached to this. On view means this is a public display location, like in a muse-um. If this field is included in the object details of an online catalogue, it could help website visitors to find out easily if the object in this location is actually on display or not. Publish means that in principle it’s okay to show the name of this location online when object details are presented in an online catalogue. This way, you could choose to publish only your public spaces of an appropriate level (gallery, garden, atrium, etc.) while omitting all private/storage locations and levels that would be inappropriate to publish (case, shelf, etc.). However, in our Axiell Internet Server web application and the WebAPI that runs it, this checkbox is not processed in any way by default. By default, no locations at all are shown in AIS. The On view and Unavailable checkboxes are inherited from parent records, so if a parent location if unavailable, the child locations in it are too by default. Yet, you can still overwrite inherited values at every level. Also handy are the new, linked Contacts fields on the Identification tab for names and phone numbers of a Location manager and Emergency contact.
Movement and shipping logistics	New	The new Movement and Shipping Logistics data source replaces both the Future Movements field group previously found in the Catalogue, as well as the Transport data source found in previous application versions. Movements of any type (incoming, outgoing, internal, external) can be planned in Movement and Shipping Logistics, whether simple single stage movements (e.g. from a storage location to a conservation studio) or chained together in complex multi-stage movements (e.g. from storage location to truck, to an internal flight, to a second truck, followed by an exhibition venue). Additional data about each movement can also be recorded, such as movement reasons and methods, or recipient and courier contact details. Lastly, the location change for linked objects can also be triggered from within the record via a status change. In the Standard model application, planning and scheduling of container movements using Movement and shipping logistics is not yet supported; this functionality is planned for an upcoming version.
Movement history	New	In previous model application versions, the location / movement history of objects was being kept on the Location history tab in object records, as a growing list of previous locations accompanied by the method and other details for moving the object from each location. In the Standard model application, the movement history has moved to it own data source where every move of an object (be it through the Change locations task or via an update import or any other way) gets its own record. (In previous model applications, the movement history was only processed if changes were made via the Change locations task.) This means that object records now have links to all their Movement history records: you can view these on the Movement history tab in an object record (click a history Reference to open a zoom screen for the linked record) or in the Related records View: clicking the Movement history header in the Related records View jumps to the Movement history data source and displays all the movement history records for the object in Result set View where you can sort them on different fields to get the best overview of that history. Having every move in a separate record provides more flexibility to work with that data and not having these detail in the object records any more makes object records leaner and therefore faster to process.
References and citations	New	References and citations holds records of instances where one or more items in your collection, or the collection itself are mentioned in a publication or other unpublished work (books, journals, catalogues, websites, etc.).
Rights and Licensing	New	The rights and licensing functionality in the Standard model application has been extended substantially, geared towards the rights specialists in your organisation. The previous Rights screen tab (or screen section) with its fairly limited set of fields for documenting (copy)rights and any licensing for their use, has been replaced by a (Linked records) – Rights and licensing tab allowing you to reference one or more rights records and/or license records in the now separate Rights and Licensing data sources. (There’s no direct link between Rights and Licensing records.) Not all objects may need rights or licensing links, but for those that do, you can scale their registration up as much as needed. While this tab is available for all records in object and archive catalogues, note that for the Moving image catalogue and the Library catalogue, the Rights and licensing tab is only available at WORK and VARIANT level. This is because these record levels represent the conceptual work which is protected by intellectual property rights and licensing.

Data sources for (Application Administrators) managing the Collections application

Coming soon

Details

With the introduction of the Standard Model all new implementations of Axiell Collections include a standard permissions model out-of-the-box and, where appropriate, the base set of roles / permissions has already been applied to application objects; for example, the source.email (se) field in acquisition.inf already has read access rights for the PII reader role, write access for the PII writer role, full access for the Data administrator and no access rights for everybody else.

This approach simplifies the permissions model, tightens security by requiring users to be a member of at least one predefined role in order to access Axiell Collections, and eliminates the need to build a permissions model from the ground up as has been the case in the past.

It is anticipated that most roles already defined in systems that upgrade to the Standard Model will map to an equivalent in the standard permissions model. And, if necessary, custom roles can of course be added.

Note: The method for assigning users to roles in Axiell Designer A tool for designing, creating, customizing and managing Axiell Collections applications and databases, broadly speaking, the Axiell Collections Model Application. As well as managing databases, including user access and permissions, Designer is used for such tasks as translating field labels, tooltips, values in drop lists, etc. is unchanged (and Application Administrators with access to this tool will continue to use it). It is anticipated however that a user access rights management tool will be made available in Axiell Collections itself in a future release, further decreasing reliance on Axiell Designer for user and permissions management.

The roles and permissions defined in the standard permissions model are:

Note: Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc.

As the bottom row in the image above makes clear, a user cannot access Axiell Collections unless they are assigned to a role. The following is a summary of permissions assigned to each group:

Active directory / Collections role	Details
Data reader / `data_reader`	A Data reader: can view but not edit records in most data sources The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on. ; cannot see fields with PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc.. If a Data reader should have permission to view PII, the user must ALSO be assigned the PII reader role.
PII reader / `pii_reader`	This role is assigned to users with the Data reader role who should ALSO be able to view PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc..
Data writer / `data_writer`	A Data writer: can view records in most data sources and can edit those records; cannot see fields with PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc.; cannot delete records. If a Data writer should have permission to view PII, the user must ALSO be assigned to the PII writer role. Note: A Data writer does not have the import or search and replace permissions.
PII writer / `pii_writer`	This role is assigned to users with the Data writer role who should ALSO be able to view and edit PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc..
Data administrator / `data_manager`	A Data administrator has super-user access and: can access all data sources (including Occurrence defaults), but not all administration data sources (such as System lists); can view, edit, and delete records; can view and edit all PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc. fields; can import data and perform search and replace.
App administrator / `$ADMIN`	The `$ADMIN` role is assigned to Application Administrators, providing full access rights and administration control. Application Administrators can access all data sources. Permissions include: view, edit, delete, import, search and replace; unlocking read-only records for editing. Also have access to tools such as Purging saved searches; restoring records using Journal Maintenance, editing record level security on records, etc.
api_svcc_account	This role is intended for the API (not users) and gives view access to relevant data sources (Catalogue, Persons and institutions, etc.), but not to PII Personally Identifying Information (PII) includes phone numbers, birth dates, gender, etc. fields.

Other changes

Details coming soon about:

Standardized record statuses
Data validation
Field tag standardization
Reset record summary task
Linear measurements
and more

Editing in Result set View and saving in Record details View

For the moment, it is not possible to edit a record in Result set View and, by default, the Edit Edit button is no longer available in the Result set View toolbar in the Standard Model. This change was introduced to ensure the integrity of your data as data entry in Result set View cannot be validated as effectively as it can in Record details View. Editing of records must now be performed in Record details View.

A consequence of this change however is that the Save button does not display in the Record details View toolbar (the Result set View edit functionality and Record details View save functionality are linked). Editing and saving of records in Record details View are both enabled by selecting the Edit Edit button.

The Standard Model

Release Notes for the Standard Model (Model Application 6.0)

Fields, panels and read-only records

Data sources

Standard permissions model

Other changes